patch
https://phabricator.services.mozilla.com/D185341
from bug 1615555 (P-256 ECDH and ECDSA from HACL*. r=jschanck)

Incorrectly used ec_field_plain as the ECC type. (lib/freebl/ecdecode.c line 156). This tells NSS to treat the field as Edwards, changing (among other things) how softoken encodes CKA_EC_POINTS. Due earlier errors here, NSS can handle both types of encodings correctly, but only DER Encoded points are corrrect for normal ECC curves (Edwards curves are encoded completely differently).

We probably need to walk through all the cases where ec_field_plain means 'use and external ECC implementation' and where it means 'this is an edwards curve'. This is even more important when the EDDSA code drops. We probably should rename it to ec_field_edwards and add an ec_field_external.

bob

This is a binary compatibility issue and it's breaking our CI.

BTW version is only nss3.94, but that's not an option in the dropdown for version.

By "our CI" you mean RedHat CI? Could you link me to a failure log and/or contribute the failing tests back to NSS?

The pkcs11-provider project CI started failing once 3.94 hit Fedora Rawhide:
https://github.com/latchset/pkcs11-provider/pull/298

After a day in GDB I found the issue is that softoken returns data encoded incorrectly for EC_POINT

it is not a straightforward thing to see from CI unfortunately, as it is deep into import export code that happens between pkcs11 tokens and openssl key import code from the providers API.

OK, I have a patch for this, it's on the try server now once I'm happy I'll push it to phabricator.

You can use dbtool to dump a database with an ECC key to see if the issue exists. Look for EC_POINT and it should have something like:

04 xx 04 xx xx xx....
If the encoding is correct. and 04 xx xx xx .. otherwise.

Add a new ec_param_xxx field for edwards curves and use it to determine whether to wrap the EC_POINTS value when we create it rather then ec_field_plain.

https://hg.mozilla.org/projects/nss/rev/a69c9f36bb8ac1c47cacb6c6ec9f06309de33951